(X08-78517)(2002).bin/ebook/promsvb6.chm/f13ph01.jpg)
The Microsoft ActiveX Data Objects (ADO) architecture is considerably less complicated than that of the DAO or RDO object model. The relative simplicity of the ADO architecture doesn't mean that learning ADO is simple, however. Even though the ADO object model has fewer objects and collections than DAO and RDO, those elements it has are often more complex than their DAO or RDO counterparts because they expose more methods and properties. A few ADO objects also expose events, which weren't implemented in DAO.
Figure 13-1 depicts the complete ADO 2.0 object model. As you can see, ADO has three main independent objects—the Connection object, the Recordset object, and the Command object—each of which exposes two collections. The Connection, Recordset, and Command objects aren't related explicitly. You create relationships among them implicitly within the running code—for example, by assigning a Connection object to the ActiveConnection property of a Recordset object. This ability to create relationships among database objects gives you an unparalleled flexibility that's unknown to DAO and RDO developers.
In this chapter, I focus on the properties, methods, and events of the objects in the ADO hierarchy. (In Chapter 14, I describe how you use these objects in database applications.) To demonstrate how ADO works, I've prepared an ADO Workbench application that lets you interactively create Connection, Command, and Recordset objects; execute their methods; see how their properties change; and watch their events fire. (See Figure 13-2.) The program is complex, with 10 modules and about 2000 lines of code, but you'll find it a very useful way to practice with ADO without having to write a single line of code. In fact, as I was using this program, I discovered several interesting details about ADO that I'll share with you in this chapter and in Chapter 14.
Figure 13-1. The ADO 2.0 object model.
One reason the ADO object model is simpler than the DAO and RDO object models is that it has fewer collections, which abound in DAO and RDO. For example, in ADO you can create any number of Connection and Recordset objects, but they are stand-alone objects and the object hierarchy won't maintain a reference to them for you. At first glance, you might believe that having to keep track of all the active objects and store them in your own collections if you want to use them later is going to make your job a bit more difficult. But when you take a closer look, you'll realize that dealing with stand-alone objects greatly simplifies the structure of your programs because in most cases you don't have to write cleanup code: When an object goes out of scope, ADO takes care of its correct termination and automatically closes open Recordsets and connections if necessary. This approach reduces memory leaking and delivers applications that require fewer resources.
(X08-78517)(2002).bin/ebook/promsvb6.chm/f13ph02.jpg)
Figure 13-2. The ADO Workbench application in action.
As you'll see in the rest of this chapter, ADO compensates for its fewer objects by having each object expose more properties than comparable objects in the DAO and RDO models do. All main ADO objects expose a Properties collection, which includes any number of dynamic properties that are specific to a given OLE DB provider and that account for the particular features of that provider. You shouldn't confuse these dynamic properties, whose availability depends on the OLE DB Provider, with the built-in properties that use the standard dot syntax and that are always available, regardless of the provider you're using.